METHOD AND SYSTEM TO PROVIDE DEDICATED CONNECTIVITY

专利摘要:
interfaces to manage direct network traffic exchanges. methods and apparatus for interfaces to manage direct network traffic exchanges. a system can include a data center, endpoint routers, and a connectivity coordinator. the coordinator implements a programmatic interface that defines connectivity operations. the coordinator receives a request for dedicated connectivity to data center resources, formatted according to the interface. the coordinator selects a target endpoint router on which to establish a physical link to implement dedicated connectivity, and transmits a response, identifying the target endpoint router and including configuration instructions for configuring a physical link to dedicated connectivity.
公开号:BR112014012931B1
申请号:R112014012931-2
申请日:2012-11-26
公开日:2021-09-14
发明作者:Kevin Christopher Miller；Andrew J. Doane；Mahmoud A. Abuelela；Michael B. Furr；David B. Lennon；Anish Sukumaran；Jeremy T. Hall
申请人:Amazon Technologies, Inc；
IPC主号:

专利说明:

FUNDAMENTALS
[0001] Many companies and other organizations operate computer networks that interconnect countless computer systems to support their operations and the services they provide to their end consumers distributed all over the world. For example, data centers that house significant numbers of interconnected computer systems have become commonplace, such as private data centers that are operated by and on behalf of a single organization, and public data centers that are operated by entities as companies to provide computing resources to consumers. In many cases, providers set up large networks that can logically span multiple regions or even countries and can include numerous data centers with varying levels of available services and facilities, used together to provide a unified set of services to their customers. finals.
[0002] In some data centers that have been configured to provide compute and/or storage facilities to remote clients, the pool of computing resources in the data center can be dynamically divided into resource pools, with each pool being available for exclusive use by a particular customer for designated periods of time. There are a number of alternatives available for how customers of these facilities establish network connectivity to the resource pools that have been designated for their use. Consumer requests can originate from a wide variety of devices - desktop personal computers, laptops, office client servers, tablets, smartphones and the like. These devices can use any long-term network links (for example, using a customer's office network with a T1 connection) to communicate with their nearby private network and/or the public Internet, or they can have connectivity transient (eg in the case where the consumer uses a smartphone phone). Networks nearby to which consumer devices are directly connected can, in turn, request to route traffic to data centers on the provider's network along a wide variety of paths. These paths, in many cases, can have somewhat unpredictable performance, reliability, and security characteristics.
[0003] For some casual types of service requests, such as a request by a consumer to read a recent article from a web-based news provider, a reasonable variation in responsiveness and an occasional drop connection may be acceptable. However, for many business-related data transmissions, such as stock quote services and stock purchase order services provided by online stock traders, or for high-bandwidth software package deployments that originate from a software development center, there may be more stringent performance, reliability, and security needs. In these environments, a provider's network consumer may require a greater level of network isolation and control than is generally available over the public Internet. For example, the customer may wish to establish, if possible, dedicated physical network links between the consumer's own network and the provider's network, such that the only traffic transmitted over these links is traffic generated on behalf of the consumer and in accordance with the policies established by the consumer. Additionally, to meet the needs of rapidly changing business, consumers may want the ability to enable and disable these dedicated links dynamically and with minimal effort and delay. BRIEF DESCRIPTION OF THE FIGURES
[0004] Figure 1 illustrates an example system, according to at least some modalities.
[0005] Figure 2 provides a high-level overview of the steps that can be taken with the help of services provided by a connectivity coordinator to establish dedicated connectivity between a customer's network and a collection of resources, accordingly with at least some modalities.
[0006] Figure 3 illustrates an example of constituent elements of a request for dedicated connectivity from a customer, according to at least some modalities.
[0007] Figure 4 illustrates an example of the constituent elements of a response to a dedicated connectivity request, according to at least some modalities.
[0008] Figure 5 illustrates an example of constituent elements of a request for a logically isolated network path, according to at least some modalities.
[0009] Figure 6 illustrates an example of the contents of a confirmation message indicating that the requested connectivity has been established, according to at least some modalities.
[0010] Figure 7 illustrates an example of two logically isolated network paths that share a physical link established using an interface provided by a connectivity coordinator, according to at least some modalities.
[0011] Figure 8 is an illustration of a portion of an exemplary web-based interface that may be provided by the connectivity coordinator, in accordance with at least some arrangements.
[0012] Figure 9 is a flowchart of a method for providing services related to connectivity, according to at least some modalities.
[0013] Figure 10 is a flowchart of a method for providing connectivity-related services, including guidance on configuring a customer's network device, according to at least some modalities.
[0014] Figure 11 illustrates an example of a system including a provider network to which connectivity from customer networks can be provided through "last mile" connectivity providers, in accordance with by minus some modalities.
[0015] Figure 12 illustrates an example of constituent elements of a request for dedicated connectivity through a connectivity provider, according to at least some modalities.
[0016] Figure 13 illustrates an example of constituent elements of a response to a dedicated connectivity request that includes information about available connectivity providers, according to at least some modalities.
[0017] Figure 14 illustrates an example communication from a client identifying a selected connectivity provider, according to at least some modalities.
[0018] Figure 15 illustrates example communications from a connectivity coordinator to a connectivity provider and a customer after the customer has selected the connectivity provider, according to a modality.
[0019] Figure 16 is an illustration of a portion of an exemplary web-based interface that can be provided to initiate connectivity provider selection, according to some embodiments.
[0020] Figure 17 is a flowchart of a method to allow customers to select connectivity providers, according to at least some modalities.
[0021] Figure 18 is a flowchart of a method for providing dynamic services related to connectivity, according to at least some modalities.
[0022] Figure 19 is a flowchart of a method that comprises the dynamic response to varying traffic levels, according to at least some modalities.
[0023] Figure 20 is a block diagram illustrating an example computer system that can be used in some modalities.
[0024] While embodiments are described herein by way of example, for various embodiments and illustrative figures, those skilled in the art will recognize that embodiments are not limited to the embodiments or figures described. It should be understood that the figures and detailed description therein are not intended to limit the modalities to the specific manner disclosed, but rather, the intention is to cover all modifications, equivalents and alternatives that are within the spirit and scope, as defined by the attached claims. Titles used in this document are for organizational purposes only and are not intended to be used to limit the scope of the description or claims. As used throughout the order, the word "may" is used in a permissive sense (ie, meaning to have the potential to), rather than in the obligatory sense (ie, meaning must). Similarly, the words "include", "including" and "includes" mean including, but not limited to. DETAILED DESCRIPTION OF MODALITIES
[0025] Various modalities of methods and apparatus for using interfaces, such as application programming interfaces (APIs) to manage dedicated network connectivity between consumer networks and provider networks, are described. Networks configured by an entity, such as a business or a public sector organization to provide one or more services accessible over the Internet (such as various types of computing or cloud-based storage) to a distributed set of customers, can be called provider networks in this document. This provider's network may include numerous data centers that host various pools of resources, such as collections of computer servers, storage devices, networking equipment, and the like, needed to implement and distribute the services offered by the provider.
[0026] In order to extend the geographic areas over which its services can be accessed with desired levels of performance, reliability and security, an operator of a provider network can establish dedicated private network paths between its data centers and one or more routers that are physically located in a remote data center facility. The facilities in which these routers are housed are referred to as "router colocation facilities" in this document as they may sometimes house routers and other network equipment owned and/or managed by commercial entities other than the network operator of the provider, such as by independent network service providers or by the customers themselves. Routers owned or managed by, or on behalf of, the provider's network operator in the router colocation facilities are referred to as "endpoint" routers in this document as they can represent the farthest points to which it extends. control of the network or ownership of network equipment. For example, only traffic that has passed through a device owned or managed by the provider's network operator, and therefore complies with the policies defined by the provider's network operator, can be allowed on private paths between peer routers. endpoints and other provider network components. In some embodiments, one or more other routers in the router's colocation facility may be part of a customer's network - that is, these routers themselves and/or managed by, or on behalf of the customers, or the other routers may have private connectivity to systems where clients of the provider's network generate service requests to the provider's network. These other routers are referred to as "client-side" ("client-side") routers throughout this document.
[0027] In order to facilitate the management of network connectivity between the customer's networks and the provider's network, in some modalities, a connectivity coordinator responsible for implementing one or more programmatic interfaces, through which the related requests the connectivity of the clients are manipulated, can be configured. A variety of different types of connectivity-related requests, such as requests to discover the types of connectivity options that may be accessible, requests to select a particular connectivity option or service, requests to set up or dismantle a hard link, and similar, may be available through the interface in different implementations. The interface can be exposed to the client in many different ways in various modalities: for example, as an API, through a graphical user interface, a web page or website, or even as a collection of commands that can be issued to from the command line prompt of a computer system.
[0028] In one embodiment, one or more collections or pools of resources in a data center may be allocated for use by a particular customer, that is, to implement the functionality necessary to satisfy requested services from devices on the network. client. In this modality, a connectivity coordinator may be operable to receive a request to establish dedicated connectivity from a client to one or more of the resource pools. The connectivity request can be generated or formatted to adapt to the interface implemented by the connectivity coordinator - for example, it can be received by submitting a web-based form, in a case where the interface is presented to the client as a set of web pages. In response to the dedicated connectivity request, the connectivity coordinator can select a specific endpoint router from the set of endpoint routers in the provider's network, as well as the destination router from which the dedicated connectivity should be provided to the requesting customer. For example, the destination router can be selected from endpoint routers available in a router colocation facility geographically closer to the customer's facility, where the customer has access to an existing customer-side router . In some implementations, the interface can allow the client to specify various details in the request that can help the connectivity coordinator choose an appropriate destination endpoint router, such as one or more facility names and/or addresses router colocation, a desired bandwidth, desired price ranges, and the like.
[0029] Having selected the destination endpoint router, the connectivity coordinator can generate configuration instructions for one or more physical network links to be established to provide the desired dedicated connectivity and transmit the instructions back to the customer in response to the customer's request. The response can also be generated to adapt to the interface implemented by the connectivity provider: for example, in a case where a web page with a form was used for the client's request, the configuration instructions can also be specified as one or more web pages, or as links to documents accessible by the web site. Configuration instructions can, for example, identify a physical location of the endpoint router, a physical port of the destination endpoint router, the rack in which it is housed, the type of connector required for the physical link, and so on. After the customer configures the physical network link in accordance with the instructions, the connectivity provider, in some arrangements, can verify that the link has been correctly configured and send a confirmation message to the customer indicating that the requested dedicated connectivity has been established. Example system environment
[0030] Figure 1 illustrates an example system environment, according to at least some modalities. System 100 may include a provider network 105 with one or more data centers 110 maintained to provide services to customers, such as cloud computing services or cloud storage services. Data centers 110, in turn, can include collections of resources such as 120A and 120B. Each resource collection 120 may include a set of resources (eg computer servers, storage devices, network devices, etc.) such as resources 112A in resource collection 120A and resources 112B in the collection of 120B resources. System 100 may also include a connectivity coordinator 114 configured to provide a connectivity service to clients, a connectivity database 115, and a plurality of endpoint routers, such as endpoint routers. ends 132A and 132B in some embodiments. Endpoint routers 132 can be connected to resource collections 120 through private network paths, such as paths 170A, 170B, 170C, and 170D. Direct use of a private network path 170, such as 170A-170D, may be limited to devices and servers on the provider's network, that is, a network packet can only be physically transmitted over a link of the private network path to from a device owned or managed by the owner of the provider's network. The term "path" as used in this document broadly refers to the set of links and devices traversed by a network message or packet between a source device and a destination device. The set of links on a given path can, in some cases, comprise a single wire, such as when the source and destination can be connected directly by a physical cable. In other cases, the path may include multiple wired and/or wireless links and various intermediary devices such as switches, gateways, routers, and the like. Paths can comprise unidirectional and/or bidirectional physical links.
[0031] In the illustrated embodiment, two example customer networks 162A and 162B representing the respective customers of the provider network 105 are shown. Each client network comprises a plurality of client devices 148 (e.g., 148A and 148B) from which requests that are finally serviced in resource collections 120 can be generated. These 148 client devices can include a variety of systems, such as desktop or rackmount computer systems, laptops, notebooks, tablets, smartphones, and the like. Some devices of the customer 148 may be housed in the premises of the customer's data office, customer data centers, or in establishments in the customer's home in various modalities, and the others may be mobile devices without any fixed physical location . In the illustrated environment, client devices 148 of a specific client have access to a client-side router - for example, client-side devices 148A of client network 162A are connected to client-side router 142A via path 160A , and client devices 148B of client network 160B are connected to client-side router 142B via path 160B.
[0032] The client-side router 142A in the example shown in Figure 1 is housed in a router 150A colocation facility, where the endpoint router 132A is also present, and the client-side router 142B is housed in a co-location facility of router 150B where endpoint router 132B is housed. In general, a number of different types of paths to various components of data center 110, such as connectivity coordinator 114 and resource collections 120, may be available from client networks 162A in various embodiments. . For example, a path 175 that does not include endpoint router 132A is shown in Figure 1 between client devices 148A of client network 162A and connectivity provider 114; this path 175 may include various routers, gateways, and public Internet devices, for example, which may or may not provide desired levels of performance, availability, reliability, or other service characteristics necessary for some of the services provided by the provider's network 105. Other paths similar to 175, but not illustrated in Figure 1, may also be available for resource collections 120 from client devices 148A and/or 148B.
[0033] The connectivity service provided by the Connectivity Coordinator 114 may include a number of techniques implemented to help the provider's network clients establish and manage the dedicated network paths from the client's networks 162 to the resource collections 120 in various modalities. For example, a cross-network connection 191, including a physical link or cable between the client-side router 142B and the endpoint router 132B, might have been established with the help of some of the connectivity service features. provided by the connectivity coordinator 114. The term cross-network connection, as used in this document, refers to a physical network connection configured between two autonomous networks. For example, within the Internet, an autonomous network can be identified by a unique Autonomous System (AS) identifier - a collection of Internet Protocol (IP) routing prefixes connected under the control of one or more network operators that presents a common, clearly defined routing policy for the Internet. In the illustrated embodiment, connectivity coordinator 114 may be operable to implement an interface that defines various connectivity operations available to customers, including establishing cross-network connections, such as connection 191, and establishing cross-network connections. logically isolated connections or paths using these cross-network links. The interface can be implemented using a variety of approaches: for example, as an application programming interface (API), a web-based interface, other graphical user interfaces, or command line interfaces, in different modalities. Connectivity coordinator 114 can also make the interface known to clients using various mechanisms—for example, a notification detailing the interface can be published to one or more corporate web sites in one modality. The connectivity coordinator 114 itself may be resident outside of the provider's network 105 in some embodiments, and in other embodiments, it may be incorporated within the provider's network 105.
[0034] Using the interface implemented by the connectivity coordinator 114, a client can generate a dedicated connectivity request. The client, in making such a request, may indicate that a physical network link (similar to the cross-network connection 191 shown in Figure 1) can be uniquely established to a client network 162A to communicate with one or more resource pools 120 , for any of a number of reasons, such as better performance, greater reliability, better security, or lower or more predictable cost. The uniqueness requirement may indicate that only traffic to or from a specified set or sets of network addresses on the customer's network should be allowed over the requested dedicated physical network link. The set or sets of physical addresses may be identified and/or modified by the client after the physical link has been configured in some implementations, ie they may not have to be specified before the initial physical link is established. The request can provide any combination of a number of different details that may be of use to the connectivity provider 114 in various ways - for example, the physical location of one or more client-side routers that could be used, a desired bandwidth and, or other service requirements. In some implementations, specific service requirements may be provided in subsequent requests after the initial request to establish that dedicated physical connectivity has been sent.
[0035] In response to receipt of this request, the Connectivity Coordinator 114 may select a specific endpoint router 132 that may be appropriate to meet the requirements of the customer. For example, the endpoint router that is physically closest to one or more customer premises, where the majority of customer requests are expected to originate without, can be chosen in an implementation. Having selected the destination endpoint router to provide the dedicated connectivity, the connectivity coordinator 114 can generate a response or notification comprising the configuration instructions for a physical network link to be established to the endpoint router. destination end 132 to provide at least a portion of the desired dedicated connectivity. Instructions can include a variety of elements in various embodiments, including, for example, a port number, rack identifier, and the like to identify the destination endpoint router. Instructions can also be generated conforming to the interface - for example, as the contents of a web page in an implementation where the request was received as a web-based form submission. In some cases, multiple responses may be sent by the connectivity coordinator - for example, a combination of one or more web responses to the requestor, and one or more email messages, some of which may be sent to other entities that not the client, such as the operator of the router co-location facility 150. The response or responses from connectivity coordinator 114 can be used to configure the required physical link. The time required to establish the physical link can vary widely depending on the responsiveness of the customer, the responsiveness of the router 150 co-location facility operator, and various procedures that may need to be completed. for security, authorization and the like. After the physical network link has been configured, connectivity coordinator 114 may, in some embodiments, transmit an acknowledgment message to the client indicating that the desired dedicated connectivity has been established. Various information related to connectivity, including, for example, data that identifies details of physical links, such as the cross-network connection 191, data that identifies the customers to which those links were established, the dates or times of establishment of dedicated connectivity and the like can be stored in connectivity databases 115 in some modalities.
[0036] In addition to the network paths illustrated in Figure 1, in many environments, there may be several other alternative network paths available between the networks of the client 162 and the various components of system 100. For example, some requests for connectivity can be transmitted to the connectivity provider 114 along a path that includes public or shared links, and the various services provided to resource collections 120 can be accessed via public or shared links as well. In some cases, alternate paths can serve as backups in case connectivity along the desired dedicated paths is interrupted. Establishing physical and logical connectivity
[0037] Figure 2 provides a high-level overview of steps that can be taken with the help of services provided by a connectivity coordinator 114 in a mode to establish dedicated connectivity between a customer network 162 and a collection of resources 120. As shown in the entry marked 201 in Figure 2, the connectivity coordinator 114 can implement an interface that defines a set of connectivity-related operations available to clients of the provider's network 105, for others. entities (such as one or more administrative officers, measurement agents, collection agents and the like) and/or other parties. The set of available operations may include, for example, operations to create, query, retrieve, update, or delete connectivity records or objects in some implementations. Available operations can be exposed through application programming interfaces (APIs), in any of a variety of standard specifications or programming languages, such as the Web Services Description Language (WSDL), XML, Java, C, C++, Python, Perl or their derivatives, in some environments, where clients can interact with the connectivity provider programmatically by issuing method calls, function calls, and the like. In other environments, in addition to or instead of providing a public API using what clients can write in code, the connectivity coordinator can provide a friendlier user interface, such as a collection of web pages. connectivity coordinator can, for example, publish a set of documents (similar to Javadocs in a case where Java or a Java programming language is used) that provide a complete list of APIs, and can expose a frequently used subset of related operations. -onada to connectivity through a webpage or pages. In this environment, a client can choose to use the webpages for common operations and can resort to programs that invoke API calls for more complex operations or for operations for which a web interface is not provided by the connectivity coordinator 114. A specific web-based interaction with the client can result in an invocation of one or more s of the APIs internally in the connectivity coordinator 114 in some of these modalities. Other types of interfaces, such as command-line tools, independently installable graphical user interfaces (GUIs) (ie, GUIs that don't rely on web pages and HTTP-based interactions), thick clients , email, or messaging protocols, can be used alone or in combination to implement the services provided by the Connectivity Coordinator 114 in various modalities. In some cases, the interface may consist of multiple layers, where one interface layer may invoke another, and one or more of the layers may be exposed to direct customer interactions.
[0038] In one embodiment, the connectivity coordinator may provide a "Getting Started Guide" or some other similar documentation that may provide examples of how the interface can be used. The following list, with entries marked API-1 through API-18, is a set of API call invocation examples that can be provided in this documentation for a subset of connectivity services provided by the connectivity coordinator 114 [API-1] Customerld customerld = createNewCustomer(CustomerInfo customerlnfo); The createNewCustomer API can be used to create a consumer account at the connectivity provider. It can take customer information (eg name, address, payment-related details) as input, and return a customer identifier. [API-2] ConnectionRequestld requestld = requestDirectConnection(CustomerId customerld, ConnectionSpecification connectionSpecification); The requestDirectConnection API can be used by a client to send a request for dedicated connectivity, with various details of the desired connectivity properties encapsulated in a ConnectionSpecification object. [API-3] RequestStatus requestStatus = getConnectionRequestStatus(CustomerID customerld, Requestld requestld); A client can use the getConnectionRequestStatus API to query the current status of a connection request - for example, the connectivity provider can indicate in the returned RequestStatus object that the current state is "in progress", "completed", or "rejected" . [API-4] Connectionld connectionld = getConnectionId(CustomerID customerld, Requestld requestld); If a Connection Object is successfully created by the connectivity coordinator (and, for example, stored in connectivity database 115), a client can use the getConnectionld API to get an identifier for that connection object. [API-5] Connectionlnfo connectionlnfo = getConnectionInfo(ConnectionId connectionld); The getConnectionlnfo API can be used to get the properties of the connection object, including such properties as the physical location of a router, a port number, traffic usage metrics, etc. [API-6] PhysicalConnectionlnfo physicallnfo = getPhysicalConnectionInfo(ConnectionInfo connectionlnfo); The getPhysicalConnectionlnfo API can be used to extract the location-specific properties of the connection object from the Connectionlnfo object. [API-7] Authlnfo authlnfo = getAuthInfo(PhysicalConnectionInfo( physical- Connectionlnfo); The getAuthlnfo API can be used to extract authorization-related information for the connection - for example, a document that allows a technician to enter the establishment where a router endpoint 132 is hosted, and making a physical network link to an endpoint router. [API-8] RequestStatus modificationStatus = modifyConnection(ConnectionId connectionld, Modificationlnfo modificationlnfo);The modifyConnection API can be used to request changes to an existing Connection - for example, to request more bandwidth [API-9] RequestStatus disableStatus = disableConnection(ConnectionId connectionld); The disableConnection API can be used to request that an existing connection be disabled, ie , that no traffic is allowed to flow over the previously configured physical link for this connection. [API-10] RequestStatus enableStatus = enableConnection(ConnectionId connectionld); The enableConnection API can be used to request that an existing (for example, currently disabled) connection be enabled. [API-11] RequestStatus deleteStatus = deleteConnection(ConnectionId connectionld); The deleteConnection API can be used to request that a connection be permanently removed. [API-12] LogicalRequestld logicalRequestld = setUpLogicalConnection(ConnectionId connectionld, LogicalConnectionParameters IcParameters); The setUpLogicalConnection API can be used to request that a logically isolated network path be configured using a pre-established physical connection and a set of logical connection properties encapsulated in a LogicalConnectionParameters object. [API-13] LogicalConnectionld logicalConnectionld = getLogicalConnectionId(LogicalRequestId logicalRequestld); A client can use the getLogicalConnectionId API to get an identifier for a specific logical connection. [API-14] LogicalConnectionlnfo logicalConnectionlnfo = getLogicalConnectionInfo(LogicalConnectionId logicalConnectionld); The getLogicalConnectionlnfo API can be used to obtain the properties of the logical connection, including such properties as the VLAN ID being used for the logical connection, and/or other routing related information associated with the logical connection. [API-15] LogicalConnectionRequestStatus modificationStatus = modifyLogicalConnection(LogicalConnectionId logicalConnectionld, LogicalConnectionModificationlnfo modificationlnfo); The modifyLogicalConnection API can be used to request changes to an existing logical connection - for example, to modify the set of network prefixes associated with it. [API-16] LogicalConnectionRequestStatus disableLogicalConnectionStatus = disableLogicalConnection(LogicalConnectionId connectionld); The disableLogicalConnection API can be used to request that an existing logical connection be disabled, that is, that no traffic is allowed to flow through the logically isolated path associated with the logical connection. [API-17] LogicalConnectionRequestStatus enableLogicalConnectionStatus = enableLogicalConnection(LogicalConnectionId connectionld); The enableLogicalConnection API can be used to request that an existing logical connection (for example, currently disabled) be enabled. [API-18] LogicalConnectionRequestStatus deleteLogicalConnectionStatus = deleteLogicalConnection(LogicalConnectionId connectionld); The deleteLogicalConnection API can be used to request that a logical connection be permanently removed.
[0039] Returning again to Figure 2, the next high-level step illustrated in 206 is the establishment of a customer account, which can be used, for example, for billing purposes. In some embodiments, the interface provided by connectivity coordinator 114 can be used (such as through an invocation of a createNewCustomer API or through a web interface which in turn invokes a similar API) to configure the customer's account. -you. In other embodiments, connectivity coordinator 114 may not be involved in account creation directly, and some other mechanism (such as interactions with an account manager component not shown in Figure 1) may be used to configure the accounts. of the customer.
[0040] A client that has an account configured can use the interface implemented by the connectivity coordinator 114 to first establish a physical link to the desired dedicated connectivity (input 211 in Figure 2), and then establish one or more network paths logically isolated that use this physical link (input 221). Finally, the dedicated connectivity functionality can be verified or validated (input 231), for example, in some embodiments, the client and/or connectivity coordinator 114 can perform one or more verification operations and confirm that the client's request has been satisfactorily implemented. Each of the high-level steps illustrated in inputs 211, 221, and 231 of Figure 2 may involve multiple interactions and/or operations at the client end and connectivity provider 114, and more details of each high-level step are provided. below. Sample requests and responses for establishing connectivity
[0041] Figure 3 illustrates exemplary elements of a request 351 for dedicated connectivity from a client, according to a modality. As shown, the request, which can be generated on a client device 148 and can be formatted in accordance with the interface provided for the services related to connectivity by the connectivity coordinator 114, comprises 360 location information, requirement of bandwidth 361, availability requirement 363, multipath requirement 365, customer networking equipment information 367, and additional specifications 368. Not all of these elements may be included in a connectivity request; any combination or subset of these and other elements may be included in requests in various modalities. In implementations where an API similar to the requestDirectConnection API described above is used, some or all of the request elements may be provided as fields of a ConnectionSpe-cification object or its equivalent.
[0042] Location information 360 may include details of a physical location where dedicated connectivity is desired: for example a street address where a client-side router 142 currently exists or where that client-side router 142 currently exists. client may need to be configured, for example, with the help of a third-party network service provider. In some cases, the customer may simply list one or more cities or even states where portions of the customer's network 162 are located and request that the connectivity coordinator 114 provide a set of possible sites where a physical connection could be configured to serve the customer network.
[0043] In some implementations, the customer can specify a desired bandwidth for dedicated connectivity through the bandwidth requirement 361. The interface provided to the customer by the connectivity provider can, for example, allow the customer to choose from one discrete set of bandwidth options, such as 500 Megabits/second, 1 Gigabit/second, or 10 Gigabit/second, where the options can be derived from the details of the specific network hardware available for establishing a physical link to an endpoint router 132. For example, in some router colocation installations, physical link options might include 1000BASE-LX (1310nm) 1Gbps single-mode fiber connections over single-mode fiber, and 10Gbps 10GBASE single-mode fiber connections -LR (1310nm) over single-mode fiber, and connectivity coordinator 114 can allow the customer to choose between the 1Gbps option and the 10Gbps option. In other cases, the client may be allowed to request any arbitrary bandwidth and connectivity coordinator 114 may respond to the request, indicating that the bandwidth is enabled or willing to provide. In an implementation, the connectivity coordinator may not provide any guarantees of bandwidth availability and instead, for example, indicate to the client that a best-effort approach will be used - that is, the connectivity coordinator will try provide as much bandwidth (up to the customer's desired limit) as possible. In another implementation, the connectivity coordinator may indicate that more than one physical link may be required - for example, if the client requests 20Gbps and the maximum available bandwidth over a single cable is 10Gbps. It may also be possible to configure multiple physical links distributed across different co-location facilities of router 132 in response to a single request for dedicated connectivity - for example, if a specific client has access to client-side routers 142A and 142B at respective facilities 132A and 132B, one or more hard links may be configured at each facility, if required or requested. The interface provided by connectivity coordinator 114 can allow clients to specify whether distinct physical locations should be used to provide the desired connectivity and, if so, how many locations should be used.
[0044] The customer may, in some modalities, also provide an availability requirement 363 and/or a multipath requirement 365. The availability requirement can be expressible in any of several metrics, such as desired maximum network outage thresholds (eg, one hour per year maximum outage time) or average time between outages. A multipath requirement 365 may indicate the number of physical links that must be configured between a client-side router 142 and an endpoint router 132. Multiple physical links may, for example, be requested for performance ( for example, so that traffic from the customer's network 162 can be load balanced or otherwise distributed over multiple physical paths, thereby reducing network congestion) for greater availability (e.g. , providing multiple paths, an alternate path may be available as a backup path in case one of the hard links fails), or a combination of performance and availability reasons. In addition to specifying how many hard links are needed, a client can also specify how traffic should be distributed between them. In a case where two paths are requested, for example, the client can specify whether they are to be established in an active/active way (eg where Multiple Paths Border Gateway Protocol (BGP) are used to balance the load between the two links and, in case of failure, one link takes over the traffic of the other), or in active/standby mode, where only one of the links is in use at a time, and the second link is activated only in case of a failure in the first link. Default options (eg active/active) may be indicated through the interface to the client in some implementations so that the client does not need to explicitly specify the multipath configuration type if the client does not wish to do so. In some cases, the indication of a 365 multipath requirement may negate the need (or contradict) of an availability requirement 363, so the customer may be allowed to specify only one of these two types of options.
[0045] In one modality, in order, for example, to further simplify the tasks that the client may need to do to establish connectivity at its end, or to optimize performance, the connectivity coordinator 114 may also be able to provide configuration instructions, suggestions and/or preferred settings for the specific type of network equipment the customer may have. In such an environment, a client may provide client network equipment information 367 to connectivity coordinator 114, which may, for example, query a database of configuration data (e.g., database 115) to look for configuration instructions for the equipment, and provide configuration suggestions or instructions to the customer. If a customer indicates through information 367 that they want to use a specific type or class of router from a specific vendor (for example, a Cisco router, a Juniper router, or a Yamaha router), for example, the connectivity coordinator may be able to to provide vendor-specific configuration tips for a specific type of router or for a specific version of software running on that specific router. These tips can include examples of how to configure or verify BGP settings, tunneling-related settings, IKE (Internet Key Exchange) settings, and can also include instructions on how to test whether the vendor-specific device is working from effectively. Troubleshooting hints and/or adjusting hints, such as preferred buffer sizes and the like, which may be vendor-specific and/or device-specific may also be provided by connectivity coordinator 114 in some embodiments. Since in at least some environments, the provider's network 105 may have a large number of customers using a wide variety of network equipment, the connectivity coordinator 114 may be able to develop a knowledge base that covers a wide variety of network equipment configurations, the types of client-side configurations that work best with the provider's network owner's equipment, and so on, which can be many useful clients that initiate the process of binding their client networks 160 to the provider's network 105. In some implementations, additional 368 specifications for desired connectivity may also be included in a customer request - for example, specifications of a desired start time or end time for dedicated connectivity, or an acknowledgment of that a specific version of BGP and/or Bidirectional Forwarding Detection (BFD) is supported on the customer's network 162.
[0046] In various embodiments, information similar to that shown in Figure 3 can be communicated in multiple steps to the connectivity coordinator 114 - for example, the location information first and the desired bandwidth can then be communicated to the coordinator Connectivity can provide a response with a list of possible options, and then, from among the possible options, the client can choose an option and provide additional specifications in subsequent messages. Information may be transmitted to connectivity coordinator 114 from the client (or a third party on behalf of the client), using any available network path - for example, a path 175 which may include portions of the public internet. Some or all of the interactions between the client and the connectivity coordinator 114 can be encoded in various modalities. In some cases where the customer does not currently have a client-side router already available at an appropriate router co-location facility 150, other interactions may be necessary between the customer and the connectivity coordinator 114, in which, for example , the connectivity coordinator provides suggestions to third-party network service providers that the customer may be able to use to gain access to a suitable router.
[0047] Figure 4 illustrates an example of constituent elements of a response that can be generated to a request for dedicated connectivity from a client, according to at least some modalities. The illustrated example shows the connectivity coordinator 114 sending a response 451 back to the client requesting device 148, as well as an optional notification 452 that can be sent to an operator or manager of a co-location facility of router 150 in some implementations. Having examined the various parameters or properties of the customer-requested dedicated connectivity, as illustrated in Figure 3, the connectivity coordinator 114 may eventually decide on a specific endpoint router 132 that may be appropriate for a physical link to be configured to the customer's network. For example, in Figure 1, endpoint router 132A in router co-location facility 150A can be chosen to provide physical connectivity to customer network 162A. The 451 response may include any combination of 471 hard link setup instructions, 482 authorization information, a 482 connection identifier, and 483 device-specific setup instructions. The 471 hard link setup instructions can, for example , identify the exact physical coordinates where a cable coming from a client-side router such as router 142A must be attached: an identification 467 of the physical port (for example, "port 3" or "the third port of the left"), a box identifier 461, a rack identifier 463, and a patch panel identifier 465.
[0048] In many cases, network equipment such as routers 132 and 142 are housed in secure environments, where not everyone can have physical access. In such cases, authorization information 481, which may, for example, comprise a legal binding agreement to allow a technician to access Endpoint Router 132A, may be provided to the customer. In some environments, a document similar to or derived from a commonly used standard authorization communication format called "LOA-CFA" (Client Facility Attribution and Authority Letter) may be used for authorization information 481. The authorization information 481 , per se, may include physical link coordinates, such as port identifier 467, box identifier 461, rack identifier 462, and patch panel identifier 465 in some cases. Response 451 may also include a connection identifier 482 corresponding to the requested dedicated connectivity, which may be used in other communications from the client to connectivity coordinator 114, such as a request to establish logically isolated paths through of the setUpLogicalConnection API described above and further discussed in conjunction with the description in Figure 5 below.
[0049] In some embodiments, connectivity coordinator 114 may also provide configuration instructions 483 to client-side network equipment. These instructions can be provided in cases where information from the 367 customer's network equipment was previously provided to the connectivity coordinator 114, and can also be provided for a standard set of devices (for example, the most commonly used types routers) even when the client has not previously provided details of client-side equipment in some implementations. Depending on the specifics of the endpoint router 132 selected for the physical connection, different sets of client-side configurations can, in general, be appropriate even for a particular piece of the client's network equipment, and the coordinator Connectivity administrators can consult their configuration knowledge base to choose the appropriate instructions after endpoint router 132 has been selected.
[0050] As described above, authorization may be required to configure physical connectivity to an endpoint router 132 in some environments. In some embodiments, authorization information 481 may also (or instead) be sent to an operator 433 of the co-location facility of router 150 by the connectivity coordinator. In some jurisdictions, legal restrictions may prevent such direct communication between the connectivity coordinator 114 and the operators of the colocation facility 433, in which case authorization information may, if necessary, be provided by the customer to the operator 433.
[0051] In many cases, a customer may be interested in using resource collections 120 for a variety of different purposes - for example, a software vendor may wish to use a resource set 112A to set up a software environment. development and compilation for your software engineers, another feature set 112B for an intranet for storing and sharing corporate information internally within the company, and a third feature set 112C (not shown in Figure 1) for an web site that can be accessed by the software vendor's customers. As a customer may wish, for example, for administrative purposes, accounting/billing purposes, and/or security reasons, that network traffic for each resource set 112 is isolated from traffic for the other resource sets 112 For example, the software vendor may wish to ensure that build-related traffic is kept separate from intranet traffic, that traffic from build machines or 112A resources are not allowed to reach one or more servers on the 112B intranet, and so on. At the same time, as a customer may wish to use the same dedicated physical connectivity provided through an endpoint router 132 for all these different functions, that is, the customer may wish to establish multiple logically isolated network paths where all share the same physical link similar to cross-network link 191 established for dedicated connectivity to resource collections 120. In some modes, the interface configured by connectivity coordinator 114 may be able to support various operations related to these paths. logically isolated, such as creating, modifying, deleting, and retrieving or querying the state of paths.
[0052] Figure 5 illustrates an example of the constituent elements of an isolation request 551 for a logically isolated path that can be sent to the connectivity coordinator 114, according to at least some modalities. Before making a request for a logically isolated network path, a client may have established a physical link to obtain dedicated connectivity, as illustrated in high-level step 211 of Figure 2, and obtained a connection identifier 482 during the process. establishment of the physical link. The connection identifier may be included in request 551 in the illustrated embodiment. Request 551 may also comprise various selection criteria, such as any combination of a VLAN ID 501, a BGP ASN 511, a set of network prefixes 521, pairing information 531, virtual private gateway information 541, and/or others information that can be useful in network isolation in various modalities.
[0053] A Virtual Local Area Network (VLAN) is a frequently used method for creating multiple logically isolated networks within a single physical network. An ID or an identifier called a VLAN ID can be inserted into the header of each packet being transmitted within a given VLAN environment to enable switches or other network devices to identify the VLAN to which the packet belongs. In one embodiment, connectivity coordinator 114 may require the client to provide a unique VLAN ID 501 for each logically isolated network path that the client wishes to establish, i.e., a client cannot be allowed to use the same VLAN ID. for multiple logically isolated paths. In one implementation, the VLAN ID 501 may be required to match a standard, such as the 802.1q Ethernet standard.
[0054] A client may also be required to provide a BGP Autonomous System Number (ASN) 511. As noted earlier, an Autonomous System (AS) is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators that have a common, clearly defined routing policy for the Internet. A single ASN is typically assigned to each AS for use in BGP routing. The ASN 511 can be public (that is, it can be exposed to multiple routers on the public Internet) or private (only exposed to the routers in the provider's network 100 and the customer's network 162), depending on the type of logical connectivity the customer desires establish in various modalities. The client can also provide a set of 521 network prefixes to be advertised to the logically isolated network, for example in compliance with BGP or other routing protocol. Pairing information 531, indicating, for example, whether the desired logically isolated path is to be paired in an active/active or active/standby mode with any other path, may also be included in request 551 in some arrangements. In some implementations, the provider's network may support the establishment of virtual private gateways to support VPN (virtual private network) functionality between a customer's network 162 and resource collections 120, and the request 551 may also include an identification of this virtual private gateway to be used for the logically isolated network path. In some embodiments, Multiple Protocol Label Switching (MPLS) techniques can be used to implement logical network isolation. While the exemplary elements illustrated in Figure 5 may be applicable in environments where BGP and related protocols are in use, in other modalities other network isolation mechanisms (eg, any other techniques usable for connecting to virtual private clouds or VPNs) ) can be provided by the customer and used by the connectivity provider for logical network isolation. In the example setUpLogicalConnection API call described above, some or all of the various elements of request 551 may be included, for example, in the fields of the LogicalConnectionParameters object passed as a parameter.
[0055] In one embodiment, after receiving request 551 to establish a logically isolated network path, connectivity coordinator 114 can perform a set of operations, such as updating connectivity database 115, propagating information from appropriate routing for various routers in the provider's network 105, updating various routing-related caches, and the like, to complete the requested configuration. After successfully establishing the logically isolated network path, in some modes, the connectivity coordinator 114 may send a confirmation message back to the client, indicating that the requested dedicated connectivity and/or logical isolation has been supplied successfully. Figure 6 illustrates an example of the contents of that confirmation message 651, indicating that the requested connectivity has been established, according to at least some modalities. In the illustrated example, the details of physical connection confirmation 601 may confirm some of the information related to the physical link established in the customer request, such as port identifier 467, rack identifier 463, available bandwidth, etc. Logical connection confirmation details 621 can confirm properties of logically isolated network paths, such as VLAN ID 501, BGP ASN 511, network prefixes 521, pairing information 531, and virtual private gateway information 541. In the illustrated example, the acknowledgment message 651 also includes connection identifier 482 and support information 611 - for example, information the customer can use to get help in the event of a traffic interruption, poor performance, or other problem that may to emerge. Acknowledgment messages 651 may exclude any combination of the elements shown in Figure 6 in different embodiments, and may include additional information in some embodiments. In one embodiment, multiple acknowledgment messages may be sent by connectivity coordinator 114 - for example, a first acknowledgment message may be sent after the hard link is established, and a second acknowledgment message may be sent after the logically isolated network path has been established. Connectivity coordinator 114 may also send instructions to the client to verify or validate that the desired connectivity is working correctly at the client end - for example, in an embodiment where resources 112 include virtual computing servers with public IP addresses and/or private, these instructions may direct the client to start a virtual computing server and alert one of its IP addresses. Example of logically isolated network paths over shared physical link
[0056] Figure 7 illustrates an example of two logically isolated network paths 752A and 752B sharing a single dedicated physical link, such as a cross-network connection established using an interface provided by the connectivity coordinator 114, in accordance with by minus some modalities. In the environment shown in Figure 2, the customer requests that connectivity be established and maintained between the internal network 732 and a restricted access resource area 712. At the same time the customer has configured a demilitarized network zone (DMZ) 722 (which may also be referred to as the perimeter network) - a subnet of the customer's network 162A that may expose some of the customer's services to the public or unreliable Internet through the public access resource area 702 within the data centers of the provider's network 105. To ensure that the traffic to the restricted access resource area 712 and the public access resource area 702 meets the desired performance, security, and cost requirements, the client may first use the interface provided by the coordinator. 114 connectivity to establish a 791 cross-network connection between the client-side router 142A and the endpoint router 132A, using, for example, the steps outlined in Figure 2. The client and can still use other interface components to establish two logically isolated network paths that share the cross-network connection 791: path 752A for traffic between DMZ 722 and public access resource area 702, and path 752B for traffic between the client's internal network 732 and the restricted access resource area 712.
[0057] In some embodiments, multiple dedicated physical links such as cross-network connections 791 or 191 may be configured on behalf of a single client, within a router 150 colocation facility or across multiple router colocation facilities. router. For example, a multinational company may have office facilities in several different countries, all of which can benefit from dedicated connectivity to a set of 120 resource collections; in that case, one or more dedicated hard links can be configured to the respective geographically separate office locations. A single physical link can be shared across a number of logically isolated paths, such as paths 752 in Figure 7. In addition, a given resource collection such as resource area 702 or 712 can be accessed through a plurality of logically isolated paths 752, where some of the logically isolated paths 752 may use different dedicated hard links 791. Web-based interface example
[0058] Figure 8 is an illustration of a portion of an exemplary web-based interface that may be provided by connectivity coordinator 114 in some embodiments. As noted earlier, the interface implemented by the connectivity coordinator 114 to provide connectivity services can be exposed to clients as a set of web pages in some modalities. Web page 800 in Figure 8 is a representation of an example of this web page that includes several form fields that a customer can fill in to provide details about the desired dedicated connectivity requirements. In some implementations, submitting form data through an interface similar to a web page 800 may result in an invocation of one or more API calls similar to those listed above, along with the description of element 201 in Figure 2.
[0059] In area 803 of web page 800, a friendly greeting and overview message can be provided. Form 805 fields can be provided to allow the customer to specify a physical location where dedicated connectivity is desired. Using the form 807 field, the customer can specify the desired bandwidth, for which a default value of 1Gbps is shown pre-selected in Figure 8. Form 809 fields can be used to provide optional pairing or multiple information ways; as shown, a pattern of two connections in active/active mode is preselected. For fields 811 can allow the client to specify a vendor name and model for a client router to be used for a dedicated physical link. The form field 813 may allow the customer to identify a network service provider that may also be involved in setting up dedicated connectivity - for example, an operator of the router colocation facility that may be used. In some embodiments, when the customer fills in address information in the 805 form fields, the connectivity coordinator 114 can automatically fill in the network service provider form field 813, or can fill in a set of drop-down options from which the customer can select a preferred provider via the form field 813. The customer can submit the completed form using the submit button 815 in the illustrated example. In some implementations, when employing a web page interface, several different web pages can be employed during the process of establishing the desired physical and logical connectivity. As the customer populates a form entry, the connectivity coordinator may be able to customize or restrict the set of options available for subsequent form entries.
[0060] Figure 9 is a flowchart of a method to provide services related to connectivity, according to at least some modalities. As shown in element 900 in the flowchart, an interface that defines a set of connectivity operations may be implemented, for example, by a connectivity coordinator 114. The connectivity operations provided through the interface may include services to configure, query, modify, disable and destroy various types of physical and logical connections, in various modalities. The interface can comprise any combination of a set of APIs, a web-based or standalone GUI, command-line tools, and the like.
[0061] A request for dedicated connectivity may be received in accordance with the interface as shown in element 910. For example, in an environment where the interface is web-based, the request may comprise one or more HTTP requests or HTTPS, while in a different modality, the request may comprise one or more method calls from a program coded and executed on behalf of the client. The request may comprise an enumeration of various details that may be needed to make a decision such as where and how dedicated connectivity can be provided, and which business entities, such as third-party network service providers or service center operators. network data, may need to be involved. For example, the request may specify a desired physical address at which a client-side router 142 is available for use, a desired bandwidth, and various other requirements.
[0062] Upon receiving the request, a destination endpoint router 132 of a provider network 105 can be selected, through which a route can be configurable to provide the desired dedicated connectivity to the customer, as shown in element 920 of the Figure 9. The destination endpoint router can be selected based on any of a variety of factors in different modalities, including physical location, measured and/or expected bandwidth utilization levels, costs, past experience positive or negative with the operator of the installation where the router is located, compatibility with the customer's network equipment and the like.
[0063] A set of configuration information and instructions can then be generated for configuring a physical link to the destination endpoint router, as shown in element 930, and a response can then be transmitted (element 940). In some modalities, the response can be submitted only to the requesting client, while in other modalities, a response can be submitted to an operator of a router 150 colocation facility, where the physical link must be established, or responses can be submitted to the requesting customer and facility operator. The answer may include data identifying the particular physical port, box, rack, and/or patch panel where a physical cable may be attached to some implementations. Authorization information, for example granting a technician permission to access the endpoint router, may be included in the response, or may be made accessible through the response.
[0064] In an implementation, after the physical link is established, a confirmation message indicating that the desired connectivity has been successfully established can be transmitted to the client (element 950 of Figure 9). In other implementations, an acknowledgment message may be generated after one or more logically isolated network paths have been established using the newly established physical link.
[0065] Figure 10 is a flowchart of a method of providing connectivity-related services, including guidance in configuring a customer's network device, according to at least some modalities. An interface, which allows a client to make a variety of connectivity-related requests, including requests for assistance in configuring one or more network devices that can be used to establish dedicated connectivity to a provider's network, can be implemented. , as shown in element 1000. A request, which provides an identification of the network equipment (for example, any combination of a vendor name, a model name, and a software version identifier for the software running on the equipment available for use by the customer, can be received (element 1010) in accordance with the interface. This request may also include other customer-requested connectivity details such as a desired bandwidth, availability/redundancy requirements, and the like.
[0066] In response to the request, in some implementations, a connectivity coordinator 114 may query a database of configuration information, for example, using a combination of vendor name, model name, software version, and/ or connectivity requirements (1020 element). If the appropriate configuration guidance is found, for example, based on the identifying information provided in the request, a response containing the configuration information or instructions can be generated (element 1030) and transmitted to the requesting client (element 1040). In some implementations, the configuration information database may include an inventory of where (that is, by which clients) different types of network equipment are being used; in this case, a record indicating that the requesting customer uses the specified equipment can be entered into the database (element 1050). Some additional information from environments in experiences with different types of network equipment, such as customer satisfaction surveys with their network equipment, average failure times, availability data and the like can also be kept in a database. knowledge by the connectivity coordinator 114, and some or all of the additional information may also be made available through the interface. Interactions with Last Mile Connectivity Providers
[0067] Figure 11 illustrates an example of a system 1105 including a 1100 provider network to which connectivity can be provided from customer networks such as 1162A and 1162B through "last mile" connectivity providers (e.g. , 1150A, 1150B, and 1150C), according to at least some modalities. In many environments, client devices such as 1148A and 1148B can be provisioned within networks (eg 1162A and 1162B) that may not have private paths available from their 1142 client-side routers to router co-location installations ( similar to installations 150 in Figure 1) where endpoint routers such as 1132A and 1132B can be located. This can be especially likely in the case of relatively small customer businesses, or where customer business establishments are located in areas that are somewhat remote from router colocation centers. These networks from client 1162 may have access through shared network paths (for example, parts of the public Internet, including, for example, parts of path 1175) to various resource collections 1120 of provider's network 1100, but operators of Customer networks may want to take advantage of dedicated paths to resource collections. Various 1150 third-party connectivity providers (ie, business entities other than the provider's network operator) may be able to provide the dedicated paths to the 1132 end-point routers - for example, in Figure 11, connectivity provider 1150C is shown providing a dedicated or direct path 1149 between endpoint router 1132B and customer network 1162B. Such connectivity providers can help customers bridge the customer's networks 1162 to the private paths 1170 (for example, paths 1170A, 1170B, 1170C, and 1170D, similar to paths 170 in Figure 1) available between the 1132 endpoint routers and the 1120 resource collections. These third-party connectivity providers may be referred to as "last mile" connectivity providers (or "last mile" connectivity providers in environments where drives distance metrics are more popular), as they are often responsible for implementing physical network connectivity closer to the customer's establishments and, therefore, further away from the establishments of the main network infrastructure providers. In this document, last mile connectivity providers may also be referred to using the abbreviation "LMCP".
[0068] Identifying that, if at all, last mile connectivity providers may be available and willing to connect a customer's network to the 1100 provider's network can often be cumbersome from a customer perspective. In some cases, a number of LMCPs may operate in the vicinity of the customer's establishments, but only a subset may be supported or preferred by the provider's network operator 1100. In the modality illustrated in Figure 11, the connectivity coordinator 1114 may be operable to implement an interface defining a variety of connectivity-related services, which can allow customers to easily determine which 1150 LMCPs can be used to connect to the provider's 1100 network. Such an interface can additionally allow customers to establish the desired dedicated connectivity (per example, along a direct path 1149) to 1120 resource collections with the help of selected last mile connectivity providers. Connectivity coordinator 1114 may implement one or more databases 1115 to store connectivity-related information, including, for example, a directory of 1150 last mile connectivity providers and their offerings. The interface can be published or made available to customers by the 1114 connectivity coordinator using any appropriate technique, such as one or more email messages to all customers on the 1100 provider's network, by establishing a website or page on the web with the interface details, and so on. The interface itself can, for example, be programmatic, and can comprise any combination of a collection of APIs, one or more web pages, command-line tools, an installable graphical user interface, or the like. Connectivity coordinator 1114 itself may reside outside of provider 1100's network in some modalities, and in other modalities, it may be embedded within provider 1100's network.
[0069] Using the interface, for example, of one of the client devices 1142A, a client can send a request for dedicated connectivity, for example, along a path 1175 that may include public Internet links. The request can, for example, include the physical address or addresses where the customer wants dedicated connectivity. In response to the request, the Connectivity Coordinator may be operable to identify one or more 1150 LMCPs that may be available to establish dedicated connections between the 1100 provider's network and the requesting customer's network (eg, 1162A), and generate and transmit a response that lists the selected LMCP or LMCPs. The selected LMCP can operate or manage one or more routers that can be co-located with one of the 1132 endpoint routers on the 1100 provider's network, or it can have the ability to configure those routers if they are no longer available. In some modalities, the 1114 connectivity coordinator can allow the client to select an LMCP from a set of available LMCPs, while in other modalities the 1114 connectivity coordinator can determine the specific LMCP or LMCPs that should be used , and inform the customer of the determination. Later, after the dedicated connectivity has been created, for example, through steps similar to those described in Figure 2, the connectivity coordinator 1114 can in some ways provide a confirmation to the client indicating that the desired connectivity has been verified. The interface can be used to communicate between the client and the 1114 connectivity coordinator during any of the stages of establishing and using dedicated connectivity - for example, a client can query the status of a requested connection or a connection established using the interface, and may request various connectivity modifications, disabling and enabling of connectivity, and the like. Responses to customer requests can also be formatted to conform to the interface.
[0070] Connectivity coordinator 1114 can, for example, look up LMCP information in database 1115 to respond to the initial request for dedicated connectivity. In cases where multiple LMCPs 1150 are available, the connectivity coordinator 1114 may in some implementations provide an ordered enumeration of all LMCPs available to the client. In other implementations, available LMCPs can be classified according to any of a variety of criteria, based on the details of the client's request and the connectivity coordinator's LMCP knowledge base. For example, if the 1114 connectivity provider is aware of the quality of service ranking or rankings of the various LMCPs, it can rank the LMCPs from highest to lowest quality. If the 1114 connectivity provider has pricing information available for the different LMCPs it can classify them according to pricing, and so on. Connectivity coordinator 1114 may in some implementations periodically query customers about quality rankings or rankings of different LMCPs and store the results of such queries in database 1115, or may monitor downtime or support requests to establish its own quality ranking. In one implementation, where customers can specify desired connectivity establishment periods (for example, the logical equivalent of "I need this connectivity by August 1, 2011 at 8:00 am"), the connectivity coordinator may be able to eliminate some LMCPs from the list of available LMCPs based on how fast the LMCPs were known to establish connectivity in the past. In some embodiments, the interface supported by connectivity coordinator 1114 may allow clients to query its knowledge base of LMCPs. In addition to the paths illustrated in Figure 11, in many environments there may be several other alternate network paths available between the 1162 client networks and various components of the 1105 system - for example, connectivity requests may be passed to the 1114 connectivity provider along a path that includes public or shared links, and various services provided to 1120 resource collections can be accessed via public or shared links as well. LMCP-related communications with the connectivity coordinator
[0071] Figure 12 illustrates an example of constituent elements of an initial request 1251 for dedicated connectivity through a connectivity provider 1150, according to at least some modalities. As shown, the request comprises location information 1260 for client network 1162, and optional connectivity details 1261, an optional start time 1268, and optional end time 1269. Connectivity coordinator 1114 can use location information 1260 as the main criteria for querying your LMCP database to identify available LMCPs. Optional connectivity details 1261 may include requirements similar to those shown in Figure 3, eg broadband requirement 361, availability requirement 363, and/or multipath requirement 365. In some embodiments the customer can also specify a desired start time 1268 and/or a desired end time 1269 - for example, indicating that dedicated connectivity will only be needed for 3 months starting January 1, 2011. start and end times may indicate that the customer only wants to use part of the dedicated connectivity time - for example the start time and end time can be specified as "08:00 to 20:00, Monday to Friday -fair". In some implementations where the desired 1268 start times are indicated by the customer, the 1269 end times may not be necessary. Timing requests comprising the desired start and/or end times may be sent separately from the initial 1251 request in some modalities.
[0072] Figure 13 illustrates an example of constituent elements of a response 1301 to a dedicated connectivity request that includes information about available connectivity providers 1150, according to at least some modalities. Response 1301 may comprise a list of one or more LMCP detail records 1361, e.g., 1361A and 1361B, that connectivity coordinator 1114 may have found to fulfill client request 1251. Different types of information about available LMCPs can be provided to the customer in various ways. For example, the LMCP 1361A detail record may comprise an identification (eg, name and contact information) 1311A of the LMCP 1150A, pricing information in fields 1321A and 1321B, estimated connectivity establishment time 1341A, and/or a 1351A satisfaction rating. Pricing information can be divided into a 1321A recurring price component (for example, "X dollars per month, regardless of actual usage") and a 1331A non-recurring price component (for example, based on usage of broadband measured by the customer). In some implementations, pricing information can be further broken down into components that must be paid to the LMCP 1150A directly by the customer, and that must be paid to the operator of the 1100 provider's network. related to pricing as separate requests in some implementations. The most remote time when the LMCP 1150A and/or provider network operator 1100 may be able to establish the desired dedicated connectivity can be indicated via field 1341A. In some cases, a 1351A satisfaction rating (for example, based on surveys of LMCP 1150A customers) may be included, which can be helpful for the customer in choosing among the available LMCPs. Detail record 1361B may include similar fields as record 1361A for a different LMCP, for example for LMCP 1150B.
[0073] Figure 14 illustrates an exemplary communication of a client identifying a selected 1150A connectivity provider, which may be generated by the client after receiving a response 1301, according to at least some modalities. The 1451 selection notification can also be formatted in accordance with the interface implemented by the 1114 connectivity coordinator, for example, as an API call or a web form selection. Figure 15 illustrates exemplary communications from the connectivity coordinator 1114 to an LMCP 1150 and to the client after the client has selected the LMCP, according to a modality. As shown, in response 1551 to the client, connectivity coordinator 1114 can provide confirmation 1583 of the selection of the LMCP. In one embodiment, connectivity coordinator 1114 may determine the LMCP 1150 to be used, for example, based on customer location information, and may not require the customer to make a selection; in other modalities, connectivity coordinator 1114 may wait for client selection or acknowledgment before making the LMCP determination. In some implementations, the client can suggest or recommend one or more LMCPs in the initial request for dedicated connectivity (for example, request 1251 in Figure 12), and the connectivity coordinator 1114 can determine the LMCP to use with based on the initial request. A connection identifier 1581 may also be provided to the client in response 1551. In some embodiments, authorization information 1582 that allows physical access to the network provider endpoint router 1132, similar to authorization information 481 shown in Figure 4, can be provided to the customer as well. In the 1552 notification sent to the selected LMCP 1150, the 1114 connectivity coordinator may also provide 1582 authorization information as well as 1571 hard link setup instructions (similar to 471 hard link setup instructions of Figure 4) that may include port, box, rack and/or patch panel identifiers 1567, 1561, 1563 and 1565 respectively for endpoint router 1132 to which a physical link may be established by or on behalf of the selected LMCP. In some embodiments, authorization information 1582 can be sent to the client or the LMCP, but not both.
[0074] After communications similar to those shown in Figure 15 are received by the client and/or the selected LMCP 1150, a path (similar to direct path 1149 of Figure 11) comprising a dedicated physical link can be established between the provider's network equipment (such as an endpoint router 1132) and client network 1162 using the selected LMCP network and/or equipment in one mode. As desired, one or more logically isolated paths similar to those discussed in conjunction with the description in Figures 5 and 7 can then be established using the newly created dedicated hard link. In some implementations, connectivity coordinator 1114 can verify, for example, by exchanging one or more network packets or messages with the client and examining the routes taken by the messages, that the desired dedicated connectivity has been provided, and can send a message. of confirmation to the client and/or to the LMCP 1150 indicating this accomplishment.
[0075] In environments where timing constraints (such as start times and/or end times) have been requested by the customer, the 1114 connectivity provider may also be operable to implement these timing constraints, for example, by changes scheduling routing or making other configuration changes at appropriate times. For example, in an environment where BGP is used as a routing protocol, a set of network prefixes for the customer's network can be announced at or just before a desired start time to enable or disable connectivity dedicated. In some implementations, the dedicated connectivity provided to a client with the help of an LMCP may have an associated bandwidth limit, and the interface supported by connectivity coordinator 1114 may also allow clients to make broadband modification requests - for example, to request a higher or lower rate of traffic than initially agreed. In response to these requests, Connectivity Coordinator 1114 can dynamically change configuration settings on one or more devices to comply with the new broadband requirement. In one embodiment, the 1114 connectivity coordinator itself can monitor the rate at which traffic flows to a customer's network 1162. If traffic over a measured period of time reaches a threshold (eg 80% or more of the traffic maximum allowed), the 1114 connectivity coordinator will be able to inform the customer that a broadband modification may be advisable, and the customer in turn may request a bandwidth increase using the interface. In some implementations, the 1114 connectivity coordinator can also be configured to notify a client if it might be advisable to lower the bandwidth limit associated with a direct de-dedicated path, for example, if measurements indicate that the client appears to use only a small fraction of the bandwidth requested. Exemplary web interface to start LMCP selection
[0076] Figure 16 is an illustration of a portion of an exemplary web-based interface that can be provided to initiate connectivity provider selection, according to some modalities. As shown, the web-based interface can include a web page 1600 with various form fields that can be presented to the customer by the connectivity coordinator 1114. The web page can include a welcome message area 1603, and 1605 form fields for the client to specify a physical address where dedicated connectivity is desired. In fields 1607, the customer can indicate whether assistance in selecting a connectivity provider is desired. Broadband requirements can be specified in field 1609, and time-related requirements for dedicated connectivity, such as a desired start time and/or a desired end time, can be specified in field 1611. Submit button 1615 can be used to send the completed form to the 1114 Connectivity Coordinator.
[0077] In one embodiment, submission of such a form may result in the invocation of one or more APIs in the connectivity coordinator similar to APIs API-1 through API-18 listed in conjunction with the description in Figure 2. Some additional APIs, including some LMCP-specific APIs and APIs to provide dynamic modification of existing connections and/or price-related operations may also be supported in some implementations, so exemplary invocations might include the following: [API-21] ProviderList providerList = getConnectionProviders (CustomerID customerld, local CustomerLocationRecord); The getConnectionProviders API can be used to find available LMCPs based on the location information specified in a CustomerLocationRecord object. [API-22] RequestStatus status = setConnectionProvider(ProviderIdproviderId, CustomerlD customerld, Requestld requestld); The setConnectionProvider API can be used to specify that a particular LMCP identified by its Providerld has been selected by the client. [API-23] RequestStatus status = setConnectionStartTime(ConnectionId connectionlD); The setConnectionStartTime API can be used to specify a start time for dedicated connectivity. [API-24] RequestStatus status = setConnectionEndTime(ConnectionId connectionlD); The setConnectionEndTime API can be used to specify a desired end time for dedicated connectivity. [API-25] Pricinglnfo pricinglnfo = getConnectionPricingInfo (ConnectionId connectionlD); The getConnectionPricinglnfo API can be used to query pricing information for an existing connection or for a connection that has not yet been established.
[0078] In some embodiments, APIs such as those for which the examples are provided above may be available for use directly by customers, 1150 LMCPs and/or other network providers, or by facility providers such as operators of router colocation facilities 150. In some implementations, multiple layers of interfaces may be supported, allowing clients to request some connectivity-related operations using a web interface, for example, and to perform or request other operations using an API.
[0079] Figure 17 is a flowchart of a method to allow customers to select connectivity providers, according to at least some modalities. The method (as shown in element 1700 of Figure 17) comprises implementing an interface that defines a set of connectivity operations made available to clients of a provider's network 1100 by a connectivity coordinator 1114. The interface may comprise an API, an command line interface, a web-based interface, some other GUI, or any other programmatic interface, for example. A request for dedicated connectivity, formatted to conform to the interface, can be received (element 1702). The request may in some cases directly indicate that the requester requires assistance in selecting a connectivity provider. In other cases the request may simply contain some information (such as a physical address where a client wants to get dedicated connectivity) from which the 1114 connectivity coordinator can infer, based on its knowledge of where the 1132 endpoint routers are from. 1100 provider's network are physically located, a connectivity provider may be required to fulfill the customer's request. As indicated in element 1704, one or more connectivity providers can then be selected, and a response to identify the selected connectivity provider or providers can be generated (element 1706 of Figure 17) and transmitted (element 1708). In some implementations the response may be transmitted to the requesting client, while in other implementations a response and/or notification may also or instead be transmitted to the selected connectivity provider.
[0080] When the client receives identifying information from candidate connectivity providers such as LMCPs 1150, it can select one (if more than one is identified by connectivity coordinator 1114) and notify the connectivity coordinator of its choice. Connectivity coordinator 1114 can then communicate with the selected LMCP 1150, and the client, to coordinate the establishment of a physical link (and in some cases one or more logical connections that use the physical link) to fulfill the requirements of client connectivity. After connectivity has been successfully established, connectivity coordinator 1114 may in some implementations send a confirmation of establishment completion (element 1710 of Figure 17).
[0081] In some embodiments a number of additional capabilities, in addition to the selection of the connectivity provider and the establishment of connectivity, can be supported through the interface provided by the connectivity coordinator 1114. Figure 18 is a flowchart of a method for the provision of dynamic services related to connectivity, according to at least some modalities. Connectivity coordinator 1114 can wait for connectivity-related requests from clients, as shown in element 1800. When a request is received, if the request is a supported type of request, connectivity coordinator 1114 can take the requested action. For example, if a dynamic connectivity enable request is received and supported in modality (element 1810), the connectivity coordinator can allow traffic to flow as shown in element 1815. In some cases enabling or disabling traffic may require interaction or coordination between connectivity coordinator 1114 and an LMCP 1150. Similarly, if the request is to disable connectivity (element 1820), the desired change can be put into effect by connectivity coordinator 1114 (element 1825). If the request is for a change to the bandwidth limits associated with the customer's dedicated connection path (element 1830), the requested change can be implemented, for example, by making configuration changes to one or more network devices in the provider's network 1100 and/or an LMCP. If the request comprises a pricing inquiry (element 1840), the 1114 connectivity coordinator can provide the requested pricing information (element 1845), which may, for example, include recurring and/or non-recurring cost information which the provider's network operator and/or the LMCP may charge the customer. If an invalid or unsupported request is received, as shown in element 1850, the connectivity coordinator can transmit a response indicating that it received an unexpected request. In each case, as the arrows leading back to element 1800 indicate, the connectivity coordinator eventually resumes waiting for connectivity-related requests. Although request type determination is shown as a series of checks in Figure 1800 for simplicity (first checking dynamic activation requests, then invalidity requests, and so on), in various implementations the type of request can be determined in a single step using logic similar to a "case" or "switch" statement in C or Java.
[0082] Figure 19 is a flowchart of a method that comprises the dynamic response to varying traffic levels, according to at least some modalities. As shown in element 1900, the connectivity coordinator can monitor traffic rates along the path dedicated to a client. If a traffic threshold is reached or maintained over a period of time (as detected in element 1910), the connectivity coordinator can provide an indication to the client that a broadband change might be appropriate (element 1915). If a request to change bandwidth is received in response to the indication (element 1920), the connectivity coordinator can implement the requested change (element 1925). The connectivity coordinator will then be able to resume monitoring the traffic. Each of the interactions illustrated in Figures 18 and 19 between the connectivity coordinator 1114 and the client can be implemented using the interface or interfaces (eg, one or more web pages) provided by the connectivity coordinator. Exemplary Use Cases
[0083] The techniques described above of providing easy-to-use interfaces for dedicated connectivity operations can be used in a variety of environments. For example, if the provider's network is rapidly expanding into new geographic regions where the reliability, performance and/or security of publicly available network facilities are limited, more and more customers may wish to utilize dedicated connectivity, especially if it is provided at a reasonable price. Also, in cases where an operator of the provider's network may already provide a set of interfaces for managing storage and/or compute resources (such as resource collections 120 or 1120) that are currently accessed via shared paths (not -dedicated), providing additional interfaces to manage dedicated connectivity options can significantly increase the rate of adoption of the dedicated connectivity services the operator has invested in.
[0084] The exemplary modalities can be described in view of the following clauses: 1. System, comprising: a data center including a collection of resources designed to respond to requests for services received from a customer; a plurality of endpoint routers connected to the data center by one or more private network paths; and a connectivity coordinator; where the connectivity coordinator is operable to: implement an interface that defines connectivity operations available to the client; receiving a connectivity request from the client for dedicated connectivity to the resource collection, where the connectivity request is formatted in accordance with the interface; in response to the connectivity request, select a destination endpoint router from the plurality of endpoint routers, where the destination endpoint router is configurable to provide a route along a private network path to one or more private network paths in accordance with the connectivity request; generating a response comprising setup instructions for a physical network link to be established to the destination endpoint router to provide at least a portion of the dedicated connectivity; and transmit the response to the customer. 2. System as reported in clause 1, wherein the interface comprises at least one of: an application programming interface (API), a graphical user interface (GUI), or a command line interface. 3. System as reported in clause 1, where the destination endpoint router is housed within a facility that requires authorization for physical access, and where the response includes an indication of a physical access authorization to the destination endpoint router at installation. 4. System as reported in clause 1, wherein the connectivity coordinator is additionally operable to: receive an isolation request from the client to establish a logically isolated network path for resource collection across the physical link; and implement a network isolation mechanism to establish the logically isolated network path in accordance with the isolation request. 5. System as reported in clause 4, wherein the network isolation mechanism comprises at least one of: a virtual local area network (VLAN) mechanism or a Multi-Protocol Label Switching (MPLS) technique. 6. System as reported in clause 1, wherein the connectivity coordinator is additionally operable to: receive, from the client, identifying information of a network device to be used to transmit the client's network traffic to the collection of resources; and provide the customer with one or more configuration instructions for the network device based on the identifying information. 7. Method, which comprises: presenting a connectivity service to a client of a provider's network, in which said connectivity service includes a connectivity coordinator, implementing a programmatic interface that defines the connectivity operations available to the customer; receiving, at the connectivity coordinator, a connectivity request for dedicated connectivity to a collection of resources on the provider's network, where the connectivity request is formatted in accordance with the interface; in response to the connectivity request, select a destination endpoint router from a plurality of endpoint routers in the provider's network, where the destination endpoint router is configurable to provide a route along from a private network to the collection of resources in accordance with the connectivity request; generating a notification comprising configuration information for a physical network link to be established to the target endpoint router 132 to provide at least a portion of the dedicated connectivity; and transmit the notification. 8. Method, as reported in clause 7, which further comprises: receiving identifying information from a network device to be used to transmit the client's network traffic to the resource collection; and provide one or more configuration instructions for the network device based on the identifying information. 9. Method as reported in clause 7, wherein the collection of resources comprises a plurality of resources, further comprising: receiving one or more selection criteria, identifying a subset of the plurality of resources so that an isolated connection is provided in the physical network link; and route network traffic in accordance with the selection criteria. 10. Method as reported in clause 9, wherein a selection criteria of the one or more selection criteria comprises a virtual local area network (VLAN) tag. 11. Method as reported in clause 7, where the destination endpoint router is housed within a facility that requires authorization for physical access, and where the notification includes an indication of a physical access authorization for the destination endpoint router at installation. 12. Method as reported in clause 7, wherein transmitting the notification comprises sending the notification to an operator of an installation in which the destination endpoint router is hosted. 13. A non-transient computer-accessible storage medium that stores program instructions which when executed in one or more processors: implement a programmatic interface that defines connectivity operations available to a client of a provider's network; receive a connectivity request from the client for dedicated connectivity to a collection of resources on the provider's network, where the connectivity request is formatted to conform to the interface; in response to the connectivity request, they generate a notification comprising configuration information for a physical network link to establish to a destination endpoint router of the provider's network to provide at least a portion of the dedicated connectivity , where the destination endpoint router is configurable to provide a route along a private network path for resource collection in accordance with the connectivity request; and transmit the notification. 14. A non-transient computer-accessible storage medium, as noted in clause 13, in which the program instructions, when executed on one or more processors: after the physical network link has been established, transmit a message confirmation indicating that dedicated connectivity has been provided. 15. Non-transient computer-accessible storage medium, as noted in clause 13, wherein the configuration information comprises at least one of: a physical port of the destination endpoint router, a rack identifier , a box identifier, or a patch panel identifier. 16. Non-transient computer-accessible storage medium, as noted in clause 13, wherein the connectivity request comprises one or more of: a bandwidth requirement, an availability requirement, or a requirement of a plurality of physical paths to the collection of resources. 17. A non-transient computer-accessible storage medium, as noted in clause 13, in which program instructions, when executed on one or more processors: receive identifying information of a network device to be used for pass network traffic from the client to the resource collection; and provide one or more configuration instructions for the network device based on the identifying information. 18. Non-transitory computer-accessible storage medium, as indicated in clause 13, wherein the collection of resources comprises a plurality of resources, in which program instructions, when executed on one or more processors: receive one or more selection criteria identifying a subset of the plurality of resources for an isolated connection to be provided on the physical network link; and generate routing information to route network traffic in accordance with selection criteria. 19. A non-transient computer-accessible storage medium, as noted in clause 18, wherein a selection criteria of the one or more selection criteria comprises a virtual local area network (VLAN) identification. 20. Non-transient computer-accessible storage medium, as noted in clause 13, where the destination endpoint router is housed within a facility that requires authorization for physical access, and where the notification includes an indication of a physical access authorization for the destination endpoint router at installation. 21. Non-transient computer-accessible storage medium, as noted in clause 13, wherein the configuration information comprises an identification of a physical location of the destination endpoint router. 22. System, comprising: a plurality of collections of resources within a provider's network, including a first collection of resources within a first geographic region of the provider's network and a second collection of resources within a second geographic region of the provider's network. provider network; an endpoint router within the first geographic zone, connecting the first collection of resources to a customer's customer network via a dedicated physical network link; and a connectivity coordinator; where the connectivity coordinator is operable to: implement an interface to receive connectivity requests from the client; receiving a connectivity request from the client to establish a logically isolated network path to the second collection of resources, where the connectivity request is formatted to conform to the interface; and performing one or more configuration operations to allow traffic to flow from the customer's network to the second collection of resources along a logically isolated network path using the dedicated physical network link. 23. System, as reported in clause 22, wherein the connectivity coordinator is additionally operable to: in response to the connectivity request, send instructions to the client to transmit connectivity metadata associated with the logically isolated network path to a destination address within of the second geographic zone; and before performing one or more configuration operations, verify that the connectivity metadata has been transmitted in accordance with the instructions. 24. System, as reported in clause 22, wherein the connectivity coordinator is additionally operable to: implement a first pricing policy for the first geographic zone, and a second pricing policy for the second geographic zone; and provide an indication of the first and second pricing policies to the customer in accordance with the interface. 25. System, as reported in clause 22, wherein the connectivity coordinator is additionally operable to: provide an enumeration to the client of one or more collections of resources to which logically isolated connections can be established on the network link dedicated physics, where the enumeration is formatted in accordance with the interface. 26. System, as noted in clause 22, wherein the interface comprises one or more of: an application programming interface, a command line interface, a graphical user interface, or a web interface. 27. Method, which comprises: presenting a connectivity service of a customer of a provider's network, in which the provider's network comprises a first geographic zone, including a first collection of resources allocated to the customer, and a second geographic zone, including a second collection of resources allocated to the client, wherein said connectivity service includes a connectivity coordinator that implements a programmatic interface defining connectivity operations available to the client; receive a connectivity request from the client to establish a logically isolated network path to the second collection of resources using a dedicated physical link established on behalf of the client to an endpoint router within the first geographic zone, where the connectivi request -ity is formatted in accordance with the interface; and performing a configuration operation to allow traffic to flow along the second logically isolated network path through the dedicated physical network link. 28. A method, as reported in clause 27, which further comprises: in response to the connectivity request, sending instructions to the client to transmit connectivity metadata associated with the logically isolated network path to a destination address within the second geographic zone; and before performing the setup operation, verify that the connectivity metadata has been transmitted in accordance with the instructions. 29. Method, as reported in clause 28, wherein the connectivity metadata is encoded in accordance with an encryption algorithm designed for secure communication between the connectivity coordinator and a network device in the second geographic zone. 30. Method, as reported in clause 27, which further comprises: implementing a first pricing policy for the first geographic area, and a second pricing policy for the second geographic area; and provide an indication of the second pricing policy to the customer in accordance with the interface. 31. Method, as reported in clause 30, wherein at least one pricing policy of the first and second pricing policies comprises a pricing indicator based on at least one of: an amount of generated network traffic, a distance in which network traffic is transmitted, the use of a load balancing mechanism or a use of a WAN (wide area network) scaling mechanism. 32. Method, as reported in clause 27, which further comprises: validating, before performing the configuration operation, whether the configuration operation complies with one or more access policies associated with the second collection of resources. 33. Method, as reported in clause 27, which further comprises: providing an enumeration to the client of one or more collections of resources to which logically isolated connections can be established on the dedicated physical network link, where the enumeration is formatted in accordance with the interface. 34. Method, as reported in clause 27, which further comprises: providing an indication to the customer of a first performance service level for traffic within the first geographic zone, and a second performance service level for traffic between the first geographic zone and the second geographic zone, in which the indication is formatted, in accordance with the interface. 35. Method, as reported in clause 27, wherein the configuration operation comprises a routing change at the endpoint router. 36. Non-transient computer-accessible storage medium that stores program instructions that when executed in one or more processors: implement a programmatic interface that defines connectivity operations available to a client of a provider's network, in that the provider's network comprises a first geographic zone comprising a first collection of resources allocated to the customer, and a second geographic zone comprising a second collection of resources allocated to the customer; receive a connectivity request from the client to establish a logically isolated network path to the second collection of resources using a dedicated physical link established on behalf of the client to an endpoint router within the first geographic zone, where the request connects. - life is formatted in accordance with the interface; and perform a configuration operation to allow traffic to flow along the second logically isolated network path through the dedicated physical network link. 37. Non-transient computer-accessible storage medium, as noted in clause 36, wherein the instructions, when executed on one or more processors: in response to the connectivity request, send instructions to the client to transmit data from connectivity associated with the logically isolated network path to a destination address within the second geographic zone on a path that excludes the dedicated physical network link; and before performing the setup operation, verify that the connectivity metadata has been transmitted in accordance with the instructions. 38. Non-transient computer-accessible storage medium, as reported in clause 37, wherein the connectivity metadata is encoded in accordance with an encryption mechanism. 39. Non-transient computer-accessible storage medium, as noted in clause 36, wherein instructions when executed on one or more processors: implement a first pricing policy for the first geographic zone, and a second policy prices for the second geographic area; and provide an indication of the second customer pricing policy in accordance with the interface. 40. Non-transient computer-accessible storage medium, as noted in clause 36, wherein instructions when executed on one or more processors: provide an enumeration to the client of one or more collections of resources to which connections logically isolated can be established on the dedicated physical network link, where the enumeration is formatted according to the interface. 41. Non-transient computer-accessible storage medium, as noted in clause 36, wherein the instructions, when executed on one or more processors: provide an indication to the customer of a first level of performance service for traffic within of the first geographic zone, and a second level of performance service for traffic between the first geographic zone and the second geographic zone, in which the indication is formatted according to the interface. 42. Non-transient computer-accessible storage medium, as noted in clause 36, wherein the instructions, when executed on one or more processors, wherein the configuration operation comprises a routing change in the point router far end. 43. A non-transient computer-accessible storage medium as referred to in clause 36, wherein the interface comprises at least one of: an application programming interface, a command line interface, a graphical user interface, or a web interface. 44. A system comprising: a collection of resources allocated to a first customer of a provider's network and connected to a first customer's network of the first customer via a first dedicated physical link; and a connectivity coordinator; wherein the connectivity coordinator is operable to: implement an interface that defines connectivity operations available to a plurality of customers in the provider's network, including the first customer and a second customer; transmit a notification formatted according to the interface to the second client, indicating that access to a service implemented by the first client in the resource collection is configurable through a path comprising a second dedicated physical link, where the second dedicated physical link connects a second customer network to the provider network; and in response to a second client's subscription request formatted according to the interface, performing one or more configuration operations to allow a request for the second client's network service to be routed to the resource collection using the second link dedicated physicist. 45. System, as reported in clause 44, in which the connectivity coordinator is still operable to: receive a service discovery request from the second client, formatted according to the interface; where the notification formatted according to the interface is generated in response to the service discovery request. 46. System, as reported in clause 44, in which the connectivity coordinator is still operable to: receive a service announcement request from the first customer, formatted according to the interface, indicating that the service is available for subscription; where the notification formatted according to the interface is generated after the service advertisement request is received. 47. System, as reported in clause 44, where the notification comprises a price indicator for the service. 48. System, as noted in clause 44, wherein the interface comprises at least one of: an application programming interface, a command line interface, a graphical user interface, or a web interface. 49. Method comprising: presenting a connectivity service to a plurality of customers of a provider's network, including a first customer and a second customer, wherein said connectivity service includes a connectivity coordinator, implementing a programmatic interface defining the connectivity operations available to the plurality of customers; transmitting, to the second client, a notification formatted according to the interface, indicating that a service implemented by the first client in a first collection of resources of the provider's network is available for subscription; and, in response to a second client's subscription request formatted according to the interface, performing one or more configuration operations to allow a request for the service from the second client's client network to be routed to the first collection of resources, using a dedicated physical link established between the customer's network and the provider's network. 50. Method, as noted in clause 49, wherein the notice comprises one or more price indicators for the service. 51. Method, as reported in clause 50, wherein one or more price indicators for the service include a first price indicator for a first time period, and a second price indicator for a second time period. 52. Method, as noted in clause 50, wherein one or more price indicators for the service include a subscription fee charged by the first customer, and a network usage fee charged by an operator of the provider's network. 53. Method, as reported in clause 50, wherein a price indicator of one or more price indicators is based on at least one of: an amount of network traffic associated with the service, or a distance over which network traffic associated with the service is transmitted. 54. Method, as reported in clause 49, which further comprises: validating, before transmitting the notification, that the notification complies with one or more access policies associated with the first resource collection; and validating, before performing one or more configuration operations, that one or more configuration operations are in compliance with one or more access policies. 55. Method, as reported in clause 49, which further comprises: before performing one or more configuration operations in response to the registration request, verifying, using one or more communications with the first client formatted according to the interface, that the subscription request is acceptable for the first customer. 56. Method, as reported in clause 49, which further comprises: receiving a service announcement request from the first customer, formatted according to the interface, indicating that the service is available for subscription; 57. Method, as reported in clause 49, which further comprises: receiving an indicator of availability of the first customer's signature field, formatted in accordance with the interface, comprising an indication of the number of available subscriptions for the service. 58. Method, as reported in clause 49, which further comprises: receiving a service discovery request from the second client, formatted according to the interface; where the transmission of the notification is responsive to the service discovery request. 59. Method, as reported in clause 49, wherein one or more configuration operations comprise establishing a logically isolated network path along the dedicated physical link. 60. Method, as noted in clause 49, wherein one or more configuration operations comprise a routing change in a router in the provider's network. 61. Non-transient computer-accessible storage medium that stores program instructions that, when executed in one or more processors: implement a programmatic interface that defines the connectivity operations available to a plurality of clients on a network of the provider, including a first customer and a second customer; transmit, to the second client, a notification formatted according to the interface, indicating that a service implemented by the first client in a first collection of resources of the provider's network is available for subscription; and, in response to a second client's subscription request formatted according to the interface, perform one or more configuration operations to allow a request for the service from the second client's client network to be routed to the first collection of resources, using a dedicated physical link established between the customer's network and the provider's network. 62. Non-transient computer-accessible storage medium, as noted in clause 61, wherein the notification comprises one or more price indicators for the service. 63. Non-transient computer-accessible storage medium, as reported in clause 61, in which the instructions, when executed on one or more processors: before performing one or more configuration operations in response to the subscription request, verifies, using one or more communications formatted according to the interface, that the subscription request is acceptable to the first customer. 64. Non-transient computer-accessible storage medium, as noted in clause 61, wherein the instructions, when executed on one or more processors: receive a service announcement request from the first customer, formatted in accordance with the interface, indicating that the service is available for subscription; 65. Non-transient computer-accessible storage medium, as reported in clause 61, in which the instructions, when executed on one or more processors: receive an indicator of first customer signature field availability, formatted accordingly with the interface, comprising an indication of the number of subscriptions available to the service. 66. Non-transient computer-accessible storage medium, as reported in clause 61, wherein the instructions, when executed on one or more processors: receive a service discovery request from the second client, formatted in accordance with interface; where notification is transmitted in response to the service discovery request. 67. A non-transient computer-accessible storage medium, as noted in clause 61, wherein one or more configuration operations comprise establishing a logically isolated network path along the dedicated physical link. 68. A non-transient computer-accessible storage medium, as indicated in clause 61, wherein one or more configuration operations comprise a routing change in a router in the provider's network. Illustrative computer system
[0085] In at least some embodiments, a server that implements a portion or all of one or more of the technologies described in this document, including techniques for implementing an interface that defines various connectivity services and operations, and for receiving and responding to various types of connectivity requests through the interface may include a general purpose computer system that includes or is configured to access one or more computer-accessible means of communication, such as computer system 2000 illustrated in Figure 20. In the illustrated embodiment, computer system 2000 includes one or more processors 2010 coupled to system memory 2020 through a 2030 input/output (I/O) interface. Computer system 2000 further includes a 2040 network interface coupled to the computer interface I/O 2030.
[0086] In various embodiments, computer system 2000 can be a uniprocessor system, including a 2010 processor, or a multiprocessor system, including multiple 2010 processors (eg, two, four, eight, or other suitable number). 2010 processors can be any suitable processor capable of executing instructions. For example, in various embodiments, 2010 processors can be general purpose or embedded processors that implement any of a variety of instruction set architectures (ISAs), such as x86 ISAs, PowerPC, SPARC, or MIPS, or any other suitable ISA. On multiprocessor systems, each of the 2010 processors can commonly, but not necessarily, implement the same ISA.
[0087] The 2020 system memory can be configured to store instructions and data accessible by the 2010 processor(s). In various embodiments, the 2020 system memory can be implemented using any suitable memory technology, such as memory static random access (SRAM), dynamic synchronous RAM (SDRAM), Flash/non-volatile memory, or any other type of memory. In the illustrated embodiment, program instructions and data that implement one or more desired functions, such as those methods, techniques, and data described above, are shown stored within system memory 2020 as code 2025 and data 2026.
[0088] In one embodiment, the 2030 I/O interface can be configured to coordinate I/O traffic between the 2010 processor, 2020 system memory, and any peripheral devices on the device, including the network interface. 2040 or other peripheral interfaces. In some embodiments, the 2030 I/O interface can perform any necessary protocol, timing, or other data transformations to convert data signals from one component (eg, 2020 system memory) into a format suitable for use by another component ( eg 2010 processor). In some embodiments, the 2030 I/O interface may include support for devices attached via various types of peripheral buses, such as a variant of the standard Peripheral Component Interconnect (PCI) bus or the Universal Serial Bus (USB) ) standard, for example. In some embodiments, the function of the 2030 I/O interface can be split into two or more separate components, such as a north bridge and south bridge, for example. Furthermore, in some embodiments, some or all of the functionality of the 2030 I/O interface, such as an interface to the 2020 system memory, can be incorporated directly into the 2010 processor.
[0089] The 2040 network interface can be configured to allow data to be exchanged between computer system 2000 and other 2060 devices attached to a 2050 network or networks, such as computing systems or devices, as illustrated in Figures 1 to 20, for example. In various embodiments, the 2040 network interface can support communication over any suitable wired or wireless general data networks, such as Ethernet network types, for example. Additionally, the 2040 network interface can support communication over telecommunications/telephony networks, such as analog voice networks or digital fiber communications networks, through storage area networks, such as Fiber Channel SANs, or through any other suitable type of network and/or protocol.
[0090] In some embodiments, system memory 2020 may be a modality of a computer-accessible medium configured to store instructions and program data, as described above for Figures 1 to 19, for implementing method modalities and apparatus for the interfaces to manage direct network traffic exchanges. However, in other modalities, the instructions and/or data of the program can be received, sent or stored in different types of media accessible by computer. Generally speaking, a computer-accessible medium may include non-transient storage media or memory media, such as magnetic or optical media, eg, disk or DVD/CD coupled to computer system 2000 via the 2030 I/O interface. A non-transient computer-accessible storage medium may also include any volatile or non-volatile media, such as RAM (eg, SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., which may be included in some modalities of computer system 2000 such as system memory 2020 or another type of memory. In addition, a computer-accessible medium may include transmission media or signals, such as electrical, electromagnetic or digital signals, carried over a communication medium, such as a network and/or a wireless link, as may be implemented. through the 2040 network interface. Conclusion
[0091] Various modalities may further include receiving, sending or storing instructions and/or implemented data, in accordance with the above description of a computer accessible medium. Generally speaking, a computer-accessible medium may include storage media or memory media, such as magnetic or optical media, for example, disk or DVD/CD-ROM, volatile or non-volatile media, such as RAM (eg, SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc., as well as transmission media or signals, such as electrical, electromagnetic or digital signals, transmitted through a communication medium such as a network and/ or a wireless link.
[0092] The various methods, as illustrated in the Figures and described in this document, represent exemplary modalities of the methods. Methods can be implemented in software, hardware or a combination of these. The order of the method can be changed, and various elements can be added, reordered, combined, omitted, modified, etc.
[0093] Various modifications and alterations can be made, as would be obvious to a person skilled in the art having the benefit of this disclosure. It is intended to cover all such modifications and alterations, and in that sense the above description should be considered in an illustrative rather than a restrictive sense.

权利要求:
Claims (14)
[0001]
1. Method for providing dedicated connectivity, CHARACTERIZED by the fact that it comprises: presenting (900) a connectivity service to a customer of a provider network, wherein the connectivity service includes a connectivity coordinator, implementing a programmatic interface comprising an application programming interface (API), a command line interface, a web-based interface or other graphical user interface, and defining connectivity operations available to the client; receive (910), at the connectivity coordinator, a client connectivity request for dedicated connectivity to computing resources or storage of a collection of resources from the provider network, where the connectivity request is formatted according to the interface; in response to the connectivity request, selecting (920) a destination endpoint router from a plurality of endpoint routers in the provider network, where the destination endpoint router is configurable to provide a route to the along a private network to the computing or storage resources of the resource collection in accordance with the connectivity request, and where the destination endpoint router is physically closest among the plurality of endpoint routers , to one or more customer establishments where a majority of customer requests served on compute or storage resources are expected to originate; generate (930) a notification comprising configuration information for a physical network link to be established to the destination endpoint router, connecting a cable to the destination endpoint router, to provide at least a portion of dedicated connectivity, wherein the configuration information comprises information indicating at least one physical port, rack identifier, box identifier, or patch panel identifier, of the destination endpoint router where a cable can be connected to establish physical network link; and transmit (940) the notification.
[0002]
2. Method according to claim 1, CHARACTERIZED by the fact that it further comprises: receiving identification information from a network device to be used to transmit the client's network traffic for the collection of resources; and provide one or more configuration instructions for the network device based on the identifying information.
[0003]
3. Method, according to claim 1, CHARACTERIZED by the fact that the collection of resources comprises a plurality of resources, further comprising: receiving one or more selection criteria, identifying a subset of the plurality of resources for which a isolated connection must be provided along the physical network link; and route network traffic in accordance with the selection criteria.
[0004]
4. Method according to claim 3, CHARACTERIZED by the fact that a selection criterion of the one or more selection criteria comprises an identification of a virtual local area network (VLAN).
[0005]
5. Method according to claim 1, CHARACTERIZED by the fact that the destination endpoint router is housed within an installation that requires authorization for physical access, and wherein the notification includes an indication of an authorization physical access to the destination endpoint router at installation.
[0006]
6. Method according to claim 1, CHARACTERIZED by the fact that transmitting the notification comprises sending the notification to an operator of an installation in which the destination endpoint router is housed.
[0007]
7. System to provide dedicated connectivity, CHARACTERIZED by the fact that it comprises: one or more processors; and a non-transient computer-accessible storage medium that stores program instructions which, when executed in the one or more processors, cause the system to: implement (900) a programmatic interface comprising an application programming interface, an interface command line, a web-based interface or other graphical user interface, and defining connectivity operations available to a client of a provider network; and receives (910) a client connectivity request for connectivity dedicated to computing resources or storage of a collection of resources from the provider's network, wherein the connectivity request is formatted in accordance with the interface; in response to the connectivity request, select (920) a destination endpoint router from a plurality of endpoint routers in the provider network, where the destination endpoint router is configurable to provide a route to the along a private network to the computing or storage resources of the resource collection in accordance with the connectivity request, and where the destination endpoint router is physically closest among the plurality of endpoint routers , to one or more customer establishments where a majority of customer requests served on compute or storage resources are expected to originate; generates (930) a notification comprising configuration information for a physical network link to be established to a destination endpoint router of the provider network by connecting a cable to the destination endpoint router to provide at least a portion of the dedicated connectivity, wherein the configuration information comprises information indicating at least one of: a physical port of the destination endpoint router, a rack identifier, a box identifier, or a patch panel identifier , where a cable can be connected to establish the physical network link; and transmit (940) the notification.
[0008]
8. System, according to claim 7, CHARACTERIZED by the fact that the program instructions, when executed on one or more processors, cause the system: after the physical network link has been established, to transmit a message confirmation, indicating that dedicated connectivity has been provided.
[0009]
9. System according to claim 7, CHARACTERIZED by the fact that the connectivity request comprises one or more of: a bandwidth requirement, an availability requirement, or a requirement for a plurality of physical paths to the collection of resources.
[0010]
10. System, according to claim 7, CHARACTERIZED by the fact that program instructions, when executed in one or more processors, cause the system to: receive identification information from a network device to be used for pass network traffic from the client to the resource collection; and provide one or more configuration instructions for the network device based on the identifying information.
[0011]
11. System, according to claim 7, CHARACTERIZED by the fact that the collection of resources comprises a plurality of resources, in which the program instructions, when executed on one or more processors, cause the system to: receive one or further selection criteria that identify a subset of the plurality of resources for which an isolated connection must be provided along the physical network link; and generate routing information to route network traffic in accordance with the selection criteria.
[0012]
12. System, according to claim 11, CHARACTERIZED by the fact that a selection criterion of the one or more selection criteria comprises an identification of a virtual local area network (VLAN).
[0013]
13. System according to claim 7, CHARACTERIZED by the fact that the destination endpoint router is housed within a facility that requires authorization for physical access, and in which the notification includes an indication of an access authorization to the destination endpoint router at installation.
[0014]
14. System, according to claim 7, CHARACTERIZED by the fact that the configuration information comprises an identification of a physical location of the destination endpoint router.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112014012931B1|2021-09-14|METHOD AND SYSTEM TO PROVIDE DEDICATED CONNECTIVITY

---

US10791096B2|2020-09-29|Interfaces to manage direct network peerings

---

US10069908B2|2018-09-04|Interfaces to manage last-mile connectivity for direct network peerings

---

US10516603B2|2019-12-24|Interfaces to manage inter-region connectivity for direct network peerings

---

US8495199B2|2013-07-23|Interfaces to manage service marketplaces accessible via direct network peerings

---

US9954763B1|2018-04-24|Pre-configured virtual gateways for isolated virtual networks

---

US10909592B2|2021-02-02|Partitioned private interconnects to provider networks

---

JP7014838B2|2022-02-01|Interface for managing direct network peering

---

AU2017206220B2|2018-06-14|Interfaces to manage direct network peerings

同族专利:

---

公开号 | 公开日

---

EP2786261A4|2015-07-08|

---

EP2786261B1|2020-02-26|

---

EP3678027B1|2022-02-16|

---

EP2786261A1|2014-10-08|

---

BR112014012931A2|2021-05-25|

---

JP6674012B2|2020-04-01|

---

EP3678027A1|2020-07-08|

---

AU2012346263A1|2014-06-19|

---

SG2014013510A|2014-07-30|

---

JP2014534789A|2014-12-18|

---

JP2016220247A|2016-12-22|

---

WO2013081962A1|2013-06-06|

---

JP2020092462A|2020-06-11|

---

JP2019071641A|2019-05-09|

---

CA2857132A1|2013-06-06|

---

CN103959273B|2018-10-12|

---

CN103959273A|2014-07-30|

---

CN109039772B|2021-08-10|

---

AU2012346263B2|2015-09-24|

---

RU2595942C2|2016-08-27|

---

CN109039772A|2018-12-18|

---

CA2857132C|2018-07-03|

---

JP6454665B2|2019-01-16|

---

RU2014121322A|2016-01-27|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

AU3792997A|1996-06-28|1998-01-21|Mci Communications Corporation|System and method for reporting telecommunication service conditions|

---

US9197599B1|1997-09-26|2015-11-24|Verizon Patent And Licensing Inc.|Integrated business system for web based telecommunications management|

---

EP1002398A1|1998-06-08|2000-05-24|Gatespace AB|Application and communication platform for connectivity based services|

---

US6459702B1|1999-07-02|2002-10-01|Covad Communications Group, Inc.|Securing local loops for providing high bandwidth connections|

---

JP4141106B2|2001-02-06|2008-08-27|富士通株式会社|Bandwidth control device|

---

US7313628B2|2001-06-28|2007-12-25|Nokia, Inc.|Protocol to determine optimal target access routers for seamless IP-level handover|

---

US7197550B2|2001-08-23|2007-03-27|The Directv Group, Inc.|Automated configuration of a virtual private network|

---

US7292577B1|2001-09-19|2007-11-06|Cisco Technology, Inc.|End-to-end preservation of VLAN priority in connection-oriented networks|

---

US7616746B2|2004-08-13|2009-11-10|Qualcomm Incorporated|Methods and apparatus for tracking and charging for communications resource reallocation|

---

JP2008523652A|2004-12-06|2008-07-03|ネクサジェント リミテッド|Interconnect system for supply chain management of virtual private network services|

---

US7373661B2|2005-02-14|2008-05-13|Ethome, Inc.|Systems and methods for automatically configuring and managing network devices and virtual private networks|

---

US7623548B2|2005-12-22|2009-11-24|At&T Intellectual Property, I,L.P.|Methods, systems, and computer program products for managing access resources in an internet protocol network|

---

US7782801B2|2007-05-29|2010-08-24|Red Hat, Inc.|Flush support for virtual synchrony|

---

US20080298374A1|2007-06-04|2008-12-04|At&T Knowledge Ventures, L.P.|Apparatus for monitoring network connectivity|

---

EP3709182A3|2008-03-31|2020-12-23|Amazon Technologies, Inc.|Configuring communications between computing nodes|

---

US8121118B2|2008-10-31|2012-02-21|At&T Intellectual Property I, L.P.|Methods and apparatus to dynamically control connectivity within virtual private networks|

---

US8028090B2|2008-11-17|2011-09-27|Amazon Technologies, Inc.|Request routing utilizing client location information|

---

US9137209B1|2008-12-10|2015-09-15|Amazon Technologies, Inc.|Providing local secure network access to remote services|

---

US8306935B2|2008-12-22|2012-11-06|Panduit Corp.|Physical infrastructure management system|

---

CN101465811A|2009-01-07|2009-06-24|上海大学|Method for obligating resource based on layered mobile IPv6 protocol|

---

US20100226280A1|2009-03-03|2010-09-09|Erf Wireless, Inc.|Remote secure router configuration|

---

US8369333B2|2009-10-21|2013-02-05|Alcatel Lucent|Method and apparatus for transparent cloud computing with a virtualized network infrastructure|

---

US20110131647A1|2009-11-30|2011-06-02|Scott Sanders|Virtual Endpoint Solution|

---

US8429704B2|2010-10-21|2013-04-23|Net Power And Light, Inc.|System architecture and method for composing and directing participant experiences|

---

EP2646905B1|2010-12-03|2020-01-22|Level 3 Communications, LLC|Virtualized connectivity in a cloud services environment|

---

CN102026390B|2010-12-31|2013-01-09|大唐移动通信设备有限公司|Base station and resource allocation method for realizing interference coordination among cells|US9692732B2|2011-11-29|2017-06-27|Amazon Technologies, Inc.|Network connection automation|

---

US9984158B2|2014-03-18|2018-05-29|Axis Ab|Finding services in a service-oriented architecturenetwork|

---

US9647883B2|2014-03-21|2017-05-09|Nicria, Inc.|Multiple levels of logical routers|

---

US9059941B1|2014-05-29|2015-06-16|Amazon Technologies, Inc.|Providing router information according to a programmatic interface|

---

US10079779B2|2015-01-30|2018-09-18|Nicira, Inc.|Implementing logical router uplinks|

---

US10129142B2|2015-08-11|2018-11-13|Nicira, Inc.|Route configuration for logical router|

---

US10057157B2|2015-08-31|2018-08-21|Nicira, Inc.|Automatically advertising NAT routes between logical routers|

---

CN106528362B|2015-09-10|2019-03-19|阿里巴巴集团控股有限公司|A kind of flow partition method and device|

---

US10095535B2|2015-10-31|2018-10-09|Nicira, Inc.|Static route types for logical routers|

---

US10153973B2|2016-06-29|2018-12-11|Nicira, Inc.|Installation of routing tables for logical router in route server mode|

---

CN107707583B|2016-08-08|2020-11-17|环旭电子股份有限公司|Cloud data transmission system and dynamic distribution method thereof|

---

US10931560B2|2018-11-23|2021-02-23|Vmware, Inc.|Using route type to determine routing protocol behavior|

---

US10797998B2|2018-12-05|2020-10-06|Vmware, Inc.|Route server for distributed routers using hierarchical routing protocol|

---

US10938788B2|2018-12-12|2021-03-02|Vmware, Inc.|Static routes for policy-based VPN|

---

JP2021072471A|2019-10-29|2021-05-06|日本電信電話株式会社|Communication system|

---

CN111818183B|2020-08-31|2021-12-03|江苏未来智慧信息科技有限公司|Power production working condition monitoring method based on equipment characteristics|

法律状态:
2018-12-04| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2019-12-24| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2021-06-01| B350| Update of information on the portal [chapter 15.35 patent gazette]|

---

2021-06-29| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-09-14| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 26/11/2012, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US13/306,775|US8724642B2|2011-11-29|2011-11-29|Interfaces to manage direct network peerings|

---

US13/306.775|2011-11-29|

---

US13/306,775|2011-11-29|

---

US13/335.465|2011-12-22|

---

US13/335,490|2011-12-22|

---

US13/335,465|2011-12-22|

---

US13/335.490|2011-12-22|

---

US13/335,490|US8495199B2|2011-12-22|2011-12-22|Interfaces to manage service marketplaces accessible via direct network peerings|

---

US13/335,465|US10015083B2|2011-12-22|2011-12-22|Interfaces to manage inter-region connectivity for direct network peerings|

---

PCT/US2012/066517|WO2013081962A1|2011-11-29|2012-11-26|Interfaces to manage direct network peerings|

---